Una vez realizado el diseño de la herramienta \texttt{Bench::Test} se
da paso a su implementación. Como en todos los proyectos, en esta etapa 
surgen dificultades y se debe hacer frente a la toma
de decisiones que afectarán directamente al resultado final.

A continuación se analizan todos los aspectos relacionados con la etapa
de implementación (dificultades, requisitos, decisiones) sin entrar en
detalles los detalles de bajo nivel (codificación).

\section{Requisitos}

El primer paso antes de empezar la codificación es definir cuáles serán
los requisitos que se impondrán al usuario final para la utilización
de \texttt{Bench::Test}.
Idealmente se debería conseguir que estos
requisitos no sean muy numerosos y si es posible, evitarlos.

\subsection{Requisitos del programa cliente}

El módulo \texttt{Bench::Test} trabaja programando ejecuciones en
distintas máquinas y filtrando las salida para obtener los valores
que realmente importan. Es por ello que el primer requisito que se
le impone al usuario es la \textit{instrumentación} de su programa,
de forma que su salida contenga \textbf{todos} los valores que puedan
tener interés (tiempo, tamaño del problema, \dots).

Como la salida será filtrada mediante expresiones regulares, sería
recomendable tener un formato que facilite la extracción de los valores
utilizando dichas expresiones regulares que el mismo usuario deberá definir.

A continuación se muestra un ejemplo de cómo podría ser la
salida de un programa correctamente instrumentado:

\newpage

\begin{verbatim}
   $ ./cutting tests/cut2D.3.dat 
   Heuristic: 1840
   Heuristic Time: 0.039420
   Problem Name: tests/cut2D.3.dat
   Global Upper Bound: 2240
   Computed nodes: 1173
   Generated nodes: 1442
   Time: 0.371814
   Sequential Solution Value: 1860
\end{verbatim}

Puede pensarse que la instrumentación del programa es algo 
trivial, pero no es así. A continuación se muestra una salida
del mismo programa \textit{mal instrumentado}. En este caso
es difícil (que no imposible) obtener los parámetros mediante
expresiones regulares:

\begin{verbatim}
   $ ./cutting tests/cut2D.3.dat
   Problem Name       Heuristic  H.Time    Seq.Solution  Time
   tests/cut2D.3.dat  1840       0.039420  1860          0.371814
\end{verbatim}

\subsection{Requisitos de la máquina}

Como ya se ha comentado, la herramienta \texttt{Bench::Test} permite
programar ejecuciones en máquinas remotas. Para ello se hace uso del 
módulo \texttt{GRID::Machine} \cite{CasianoGridMachineDoc}. 

El módulo \texttt{GRID::Machine} permite realizar llamadas a procedimientos
remotos (\textit{RPC}) mediante un enlace \textbf{SSH}. Para que ésto sea 
posible se debe tener acceso automático sin contraseña a cada una de las
máquinas sobre las que se desea lanzar las ejecuciones. (véase el apéndice
``\textit{Login SSH automático}'' del capítulo \ref{chapter:ssh}).

\subsection{Interfaz de usuario ¿Cómo se usa?}

Una vez diseñadas las interfaces entre objetos, sólo resta definir
la forma en la que el usuario define los parámetros que permiten
guiar las ejecuciones.

En principio, el usuario debe escribir un script Perl que cree un objeto
de la clase \texttt{Bench::Test} pasando al constructor todos
y cada uno de los parámetros que guían las ejecuciones. A continuación se
debe invocar alguno de los métodos (\texttt{make\_test} o \texttt{create\_test})
que llevan a cabo las ejecuciones para mostrar los resultados al usuario,
o para almacenar los resultados respectivamente (véase la documentación
del módulo \texttt{Bench::Test} en el capítulo \ref{chapter:Bench-Test}).

Este proceso, aunque sencillo, requiere del usuario un mínimo de
conocimiento de la sintaxis del lenguaje Perl para 
cargar los módulos necesarios, crear un objeto, e invocar métodos.

No todo el mundo es amante del lenguaje Perl, así que para evitar
lo máximo posible la escritura de código Perl por
parte del usuario se decidió crear dos pequeños scripts que realizaran
las tareas descritas. El nombre de estos scripts es \texttt{maketest} y
\texttt{createtests} y se encuentran disponible dentro de la carpeta
\texttt{/script} de la distribución (véase la documentación de dichos
scripts en los capítulos \ref{chapter:maketest} y \ref{chapter:createtests}).

Gracias a estos dos scripts, el usuario se
desentiende de la creación del objeto. La forma
que tiene de definir los parámetros correspondientes es mediante
la escritura de un fichero de configuración cuyo nombre por defecto
es \texttt{maketest.conf}. Más adelante en esta memoria se detallará
el contenido de dicho fichero de configuración.

Para aquellos usuarios que la escritura de dicho fichero de
configuración les suponga un obstáculo muy grande por estar escrito con
sintaxis Perl, se provee otro script (\texttt{configcreate}) que
automatiza este proceso sin necesidad de escribir código Perl
(véase la documentación del script \texttt{configcreate} en el
capítulo \ref{chapter:configcreate}).

\section{Dependencias}

El módulo \texttt{Bench::Test} necesita la instalación de otros módulos
para funcionar correctamente. Los módulos necesarios son:

\begin{itemize}
\item \texttt{GRID::Machine}
\item \texttt{Template}
\item \texttt{Storable}
\end{itemize}

El módulo \texttt{Storable} viene ya instalado con la distribución de
Perl, pero los módulos \texttt{GRID::Machine} y \texttt{Template} han
de ser instalados por el usuario (véase el apéndice
``\textit{CPAN. Instalación de módulos}'' en el capítulo
\ref{chapter:cpan})

\section{Almacenamiento del resultado de las ejecuciones}

El módulo \texttt{Bench::Test::Base} permite acceder a los resultados de
ejecuciones realizadas en el pasado que se quisieron almacenar. Ante la
forma de almacenar estos datos puede surgir una duda.
¿Almacenar la salida intacta o almacenar la salida filtrada?  Cualquiera
de las opciones tiene sus ventajas e inconvenientes.

En un primer momento se podría pensar que almacenando la salida filtrada
se ahorra tiempo cada vez que se accede a ella puesto que no debe
filtrarse una y otra vez. Sin embargo, es posible que el usuario cuando
realiza las ejecuciones no esté interesado en ciertos parámetros que en
el futuro sí podrían ser útiles. Si se almacena la salida filtrada, estos
parámetros se pierden para siempre.

Por ello, las salidas de las ejecuciones son almacenadas \textbf{intactas}
de forma que no se pierda ninguna información que pueda ser útil, sobretodo,
en el futuro.

Además, el procesado de la salida del programa (recuérdese que se trata de
texto plano) no es una operación costosa, así que la posible ganancia de almacenar
la salida filtrada no es tanta en comparación con los más que probables
inconvenientes.

\section{Dificultades}

Las mayores dificultades encontradas durante la etapa de implementación
fueron las relacionadas con la depuración de errores. Como se dijo en
la introducción, el lenguaje \textbf{Perl} es un lenguaje muy potente,
pero muy \textit{permisivo}.

La carencia de un conjunto generoso de tipos de datos y el hecho de ser
un lenguaje interpretado provoca que, en muchas ocasiones, un error
de codificación no sea detectado hasta que una prueba en concreto lo
delata.

Si a esto se suma la posibilidad de que el error provenga de algún
conflicto con los permisos (permisos, variables de entorno, etc.)
en cualquiera de las máquinas remotas donde se están realizando
las ejecuciones, el panorama se presenta verdaderamente complicado. 

